home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text0548.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.0 KB  |  62 lines
  1. >> Beacuse
  2. >>each XMP section is like a black box, any white spce inside it would not be  
  3. >>seen by the white space management logic which overlaps the white spaces  
  4. >>required around successive paragraphs, and extra white spce would result.
  5. >
  6. >Unfortunately, this conflicts with the SGML standard. An SGML parser
  7. >will report
  8. ><XMP>
  9. >foo
  10. ></XMP>
  11. >
  12. >as
  13. >an XMP start tag
  14. >the string "foo" [NOT "\nfoo\n"]
  15. >an XMP end tag
  16. >
  17. >And so it is, strictly speaking, illegal to treat the above markup
  18. >differently from
  19. ><XMP>foo</XMP>
  20. >
  21. >I'm not sure how we should resolve this.
  22.  
  23. This was almost the exact example I was playing with when I decided to start
  24. this messy discussion.  Also some paragraph examples.  Both of the following
  25. should mean the same:
  26.  
  27. some text<P>more text
  28.  
  29. and
  30.  
  31. some text
  32. <P>
  33. more text
  34.  
  35. The latter being commonly used.  I realized that unless you could remove
  36. surround new-lines in cases like this, the second paragraph would start
  37. with a space.  Similarly, you might find headings, or other things with
  38. a space at the beginning.
  39.  
  40. >>    PRE
  41. >>
  42. >>By the way, I think we agreed (I gave in) that the <PRE> sections would have
  43. >>siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which
  44. >>gives double spacing on my browsers.  So I tread newlines as newlines in all
  45. >>the <PRE> element just as XMP.
  46. >
  47. >This is a situation we need to resolve, one way or another. I'm inclined
  48. >to decide that <p> elements are allowed in PRE elements, but they have
  49. >no significance. They were put there to cause the old linemode browser
  50. >to break the line, so they have always been redundant. So Tim's treatment
  51. >of newlines in PRE is correct, but his treatment of <P> there is not
  52. >[by this new convention.]
  53.  
  54. Note that the method I proposed has the advantage of automatically dealing
  55. with this (sort of).  If the document was converted simply by adding a <P>
  56. to the end of each line, then for such lines, I remove the newline but keep
  57. the <P>.  Then the code that deals with PRE sections can happily honor
  58. both new-lines and <P> tags, thus making it compatible with either style.
  59.  
  60.     tom
  61.  
  62.